Windows Azure : Programming Access Control Service (part 10) - Deploying the Web Service in Windows Azure

3. Deploying the Web Service in Windows Azure

Once you have tested the claims-based authentication and authorization for the ACSMachineInfo web service, you can package and deploy the web service as a Windows Azure cloud service. The steps required for packaging and deploying the ACSMachineInfo web service as a Windows Azure cloud service are as follows:

Figure 14 shows the project structure for the cloud service and the worker role projects.

Figure 14. Cloud Service Project Structure

The ACSCloudService project is a Windows Azure cloud service project and the ACSMachineInfoWorker is the worker role that contains the implementation of the service. The movement of the service from regular WCF to a worker role cloud service should have minimal impact on the client because the web service Url remains the same.

Because the worker role does not have a default external (or input) endpoint, you need to create an external http endpoint for the worker role on port 80, so that all the http requests to the web service Url are received by the web service. Figure 15 shows the configuration setting for the external endpoint on port 80.

Figure 15. External Endpoint on port 80

The external endpoint configuration makes port 80 available to the web service for exposing external interface. The web service still needs to create a service on that port. Listing 15 shows the code for the Run() method in the worker role. The ACSMachineInfo web service is initialized on port 80 of the cloud service in this method.

Example 15. Worker Role Run method

const string serviceNamespace = "proazure-1";
const string trustedTokenPolicyKey = "8O++r46Eo6e6VhGQaHSCfINhYMMCu14xsAectW2EFfk=";

const string acsHostName = "accesscontrol.windows.net";
const string trustedAudience = "http://localhost/acsexample";
const string requiredClaimType = "action";

public override void Run()
{

    WebHttpBinding binding = new WebHttpBinding
(WebHttpSecurityMode.None);

    Uri address = new Uri(trustedAudience);

    WebServiceHost host =
new WebServiceHost(typeof(ACSExample));
    host.AddServiceEndpoint(typeof(IACSExample),
binding, address);

    host.Authorization.ServiceAuthorizationManager =
new ACSAuthorizationManager(
        acsHostName,
        serviceNamespace,
        trustedAudience,
        Convert.FromBase64String(trustedTokenPolicyKey),

					  

requiredClaimType);

    try
    {
        host.Open();
        while (true)
        {
            Thread.Sleep(10000);
          }
    }
    finally
    {
        host.Close();

    }
}

The code for initializing the web service is tan exact replica of the code from the WCF service that we deployed earlier in the article. Observer the Url for the web service does not change and because external endpoint is available on port 80, the service will be available publicly for consumption, provided the client gets authenticated by ACS.

To test the cloud web service in development fabric, select ACSCloudService and press F5 to run the web service in debug mode. Figure 16 shows the ACSMachineInfo web service running as worker role in development fabric.

Figure 16. ACSMachineInfo Web Service as Worker Role

Next, to test the client access, you can either run the client that generates SWT or client that acquires SAML token from a local STS. Figure 17 shows the command line output from the client that generates SWT locally and then calls ACS for authentication before calling the web service.

Figure 17. Web Service Client calling cloud web service with ACS authentication

After the certificate is created, you can use it in any application that requires X.509 certificates. You can also share the same certificate across multiple applications.

The AppFabric ACS doesn't support WS-Trust and WS-Federation. As you saw from the examples, the protocol is REST-based and so can be easily used from multiple platforms. The core functionality of ACS is to map input claims to output claims by abstracting multiple input claims from multiple sources to a consistent set of output claims expected by the relying party. The relying party doesn't have knowledge of the input claim source; it trusts the output claims issued by ACS. The ACS management service API provides functions to create these mappings.